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REMARKS/ARGUMENTS 

Claims 30-65 were pending. 

In the Office Action, the Examiner rejected claims 30-52 and 60-65 under 35 
USC §101 (the Office Action stated "claims 1-29" and later "claims 30-52 and 60-65" and we 
interpreted that to mean the latter as claims 1-29 were earlier withdrawn), rejected claims 30-65 
under 35 USC §112, first paragraph as failing to comply with the written description 
requirement, and rejected claims 30-65 under 35 USC § 103(a) as being unpatentable over 
Glynias, et al. (US Patent No. 6,125,383). 

In response to the rejection under 35 USC §101, the Examiner is apparently 
rejecting the claims as lacking limitations to hardware or other physical structures and asserting 
that software and data alone are nonstatutory subject matter. Applicant respectfully traverses the 
Examiner's position, but in an effort to advance prosecution, independent claims 30, 53 and 60 
have been amended to recite elements that clearly make each of the claims statutory subject 
matter. Those amendments do not introduce any new matter, as computer embodiments are 
supported by the original filed application. See, for example, Fig. 3 and related text, such as 
page 30, lines 9-16. 

In response to the rejection under 35 USC §112, first paragraph, Applicant 
submits that each of the claim terms are supported by the specification. To advance prosecution, 
some of the claims have been amended to clarify support. The Examiner listed a number of 
claim terms from claims 30, 53 and 60 and asserted a la'ck of clear support. Those elements are: 
- "data structuring object": At least one example of a data structuring object is disclosed 
and explained in the specification. See, for example, an intelligent molecular 
object (IMO), such as an IMO 502, shown in Figures 5, 6, and 7 and described on 
page 16, lines 5-25 of the originally filed specification, among other references. 
As described, an IMO reviews "raw" data content and structures that data, and is 
an example of a data structuring object. See also page 33, lines 27-29 and page 
61, lines 18-19. Structuring data might include identification of data subset 
boundaries and extraction, normalization and access of information contained 
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within those boundaries in order to, for example, compare the information subsets 
with similar information contained within other data sets for statistical or 
visualization purposes, or for comparison to submitted queries. For reference, see 
page 24, lines 10-14. In a specific example of data structuring, data field mapping 
is done and vectors are generated for accessing specific data fields. See page 20, 
line 21-24; page 61, lines 31-32 and page 62, lines 1-4. It should be understood 
that the above references to the specification are not to be construed as limiting 
the claims, but merely cite examples of support in the specification. 

- "native data content": This element is no longer used in the claims, however it should 

have been apparent that "native data" is taught by teachings of the use of raw 
data, such as described in a number of places in the specification. As explained in 
the specification, the data structuring objects can operate on raw data content as 
opposed to requiring a conversion from the raw data to restructured form. 

- "common user presentation interface and interaction format": This element is no longer 

used in the claims, however it should have been apparent that the element is 
taught in the original specification. Examples of common user presentation 
interfaces are shown in at least Figs. 7, 13 and 17a-c, the interaction format is a 
format suitable for presentation. 

- "a master ontology": This element is no longer used in the claims, however it should 

have been apparent that the element is taught in the original specification. An 
ontology is a specification that represent the formal identity of data, including 
information such as relevant units of measurement, data source information, 
available actions or commands, content (data attribute), history (data state), 
relationships (including calibration, normalization and translation requirements) 
and related concepts assumed to exist in an area of interest. An example of a 
master ontology generator is the object translation engine, however to advance 
prosecution, "master ontology" was deleted from the claims. Object translation 
engines are clearly supported in the original specification, such as in Figs. 1 1 and 
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12. See also cites on page 40, lines 18-20; page 41, lines 32-33; page 42, lines 1- 
4 and elsewhere. 

- "an ontology of data structuring objects": This element is no longer used in the claims; 

however it should have been apparent that the element is taught in the original 
specification. An ontology is a specification that represents a formal identity of 
data, including information such as relevant units of measurement, data source 
information, available actions or commands, content (data attribute), history (data 
state), relationships (including calibration, normalization and translation 
requirements) and related concepts assumed to exist in an area of interest. An 
ontology of data structuring objects is supported by at least the set of definition 
tables defined in the original disclosure, however to advance prosecution, "an 
ontology of data structuring objects" was deleted from the claims. Definition 
tables are clearly supported in the original specification. See, for example, Fig. 9, 
page 11, lines 16-25; page 67, lines 11-12 and elsewhere. 

- "data point": Data points are well known in data processing and need not be explained 

in detail. A data set is a collection of data points. 

- "pointer to a source of the data item": A pointer is well known in programming fields as 

a device to direct a program to a particular location. Examples of pointers in the 
specification include vector paths, file paths, URLs and other objects that operate 
as pointers. The specification discloses that pointers can point to sources and in 
particular to sources of data items pointed to by data objects. For example, an 
intelligent molecular object (IMO) is a data object that includes pointers to the 
source of the data associated with the data object. See, for example, page 23, 
lines 32-33 describing how an IMO can include a pane that included pointers to 
an original image file, where the image file contains the data associated with the 
data object. See also, page 14, lines 12-14, wherein the specification states: 
". . .By using meta-data reference tables, pointers and tags to provide real-time 
translation and integration, which efficiently refers only to the aspects of any raw 



Page 12 of 16 



Appl. No. 10/010,086 PATENT 

Amdt. dated April 4, 2005 

Reply to Office Action of January 6, 2005 

data relevant to a specific query, the IMO IT Platform avoids data redundancy and 
data access locking requirements." 

- "common user presentation and interaction layers": This element is no longer used in 

the claims. 

- "intermediate data format": The "IMO" data format described at least at page 9, first 

full paragraph ("Data type translators are provided to automate transformation 
from heterogeneous data sources into MO data in real-time.") The IMO data 
format is an intermediate data format. Other examples of various intermediate 
data formats include a global standard format ("These algorithms allow for the 
extraction of variable and non- variable regions within a set of data and generate a 
global standard to which all data can be referred."; page 20, lines 7-9), tables for 
property pane presentation ("An Application Definition Generator (ADG) 
component is provided, which automates the query of application and database 
requirements and is comprised within related translation components to generate 
tables required for integrated real-time property pane presentation at the data 
object level."; page 21, lines 8-1 1). 

- "common format": This term appears in claim 60 in the element of "translation means 

for converting data associated with different data items into a common format". 
Applicant submits that it should be apparent from the context of the original 
specification and the claim language that data from different data items can be 
translated into a common format, i.e., a format that is common to the translated 
data items. See page 9, lines 9-12 and page 12, lines 5-7 in the original 
specification, which describe automating transformation from heterogeneous data 
sources to an empirically normalized data standard. That data standard would be 
a common format, as data from heterogeneous data sources would be transformed 
into a format that is common among the data. Other areas of the original 
specification describe other variations on transforming to a common format. See 
also for example, page 20, line 28 and page 21, lines 18-21. 
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- "data attributes and object attributes": The Examiner's objection is not well understood, 

but the point should be moot as this element is no longer used in claim 60, 
although data attributes does appear in other claims. Data attributes are clearly 
supported by the specification, at least as a type of meta-data. See page 10, line 
25. 

- "native form": This element is no longer used in the claims. 

- "data content subset relationships": This element has been amended to recite "data 

relationships and data subset relationships". The specification as originally filed 
described apparatus for analyzing and otherwise defining relationships between 
data that were previously difficult to compare. In some embodiments described, 
this is done using IMOs, which represent original data in a standardized 
environment. Data relationships and apparatus and methods to analyze and 
define them are described in the specification as originally filed at, for example, 
page 51, lines 14-15 and page 55, lines 9-10; and page 20, lines 2-5. Data 
relationship definition via objects is further described at page 17, line 33 and page 
18, lines 1-3. Finally, Figure 17B, which is described on page 55, lines 5-6, 
shows a graphical example of data relationships depicted using a dendrogram. As 
the specification explains, data relationships can also be analyzed as subsets, for 
example, through vectors and meta-data link descriptions. Data subset 
relationships might be defined through comparison as explained on page 20, lines 
20-23. Figure 17C, provides a graphical depiction of data subset relationships, in 
that example showing several dimensions of data compared in cluster 
visualization format. 

- "content relationships": This element is no longer used in the claims. 

Applicant submits that the above comments and the amendments to the claims 
satisfy the requirements of the request for information under 37 CFR §1.105. 
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35 USC§ 103(a) Rejection 

In response to the rejection under 35 USC § 103(a), Applicant submits that 

Glynias fails to disclose or suggest each element of the independent claims 30, 53 and 60, as 

amended and therefore each of the claims are allowable over that reference. 

Glynias fails to disclose or suggest each element of independent claim 30. For 
example, claim 30 as amended recites "at least one subset vector within the data structuring 
object", which is not disclosed or suggested by Glynias. Subset vectors within data structuring 
objects describe subsets of associated raw data. Glynias may provide wrappers around raw data, 
but this is not the same as having vectors representing subsets of the data. As explained in the 
specification, by referring to only a subset of the raw data reduces network traffic (as the entire 
data set need not be transferred) and use of raw data may eliminate the need for pre-converting 
data before use. Processing is done on typically small data subsets. Since vector subsets are 
defined, generated and used and may be applied to subsets of raw or object data, network traffic 
and processing burdens are minimized, and data integrity is maintained. See page 37, lines 4-7; 
page 20, lines 20-30 and page 61, line 18-20, respectively. 

While Glynias does disclose lists of project manager items and calls these lists 
"vectors", they are not subset vectors. Glynias' vectors identify available items by Java classes 
that can implement those available items, whereas subset vectors identify subsets of data in 
associated raw data. 

Glynias also fails to disclose or suggest each element of independent claim 53. 
For example, claim 53 as amended recites "accessing vector subsets of data corresponding to the 
data item in a raw data format", which is not disclosed or suggested by Glynias. Applicant 
submits that in view of the other amendments to claim 53, this step must be given patentable 
weight. 

Glynias also fails to disclose or suggest each element of independent claim 60. 
For example, claim 60 as amended recites "master query search means for searching data objects 
as vector subsets", which is not disclosed or suggested by Glynias as Glynias does not deal with 
vector subsets. 
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In view of the above, Applicant submits that each of the Examiner's requests and 
rejections have been addressed by the amendments to the claims and these remarks. 



In view of the foregoing, Applicants believe all claims now pending in this 



Application are in condition for allowance. The issuance of a formal Notice of Allowance at an 
early date is respectfully requested. 

If the Examiner believes a telephone conference would expedite prosecution of 
this application, please telephone the undersigned at 415-576-0200. 
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TOWNSEND and TOWNSEND and CREW LLP 
Two Embarcadero Center, Eighth Floor 
San Francisco, California 941 1 1 -3834 
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CONCLUSION 
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